One of the most important tasks performed by users of a database management system, such as database administrators (DBAs), is to provide stable performance in the presence of changes to the database system. When these changes are made to the database system, DBAs must ensure that the database system performance and end-user satisfaction will not regress. This task is, however, a challenging and time-consuming one because of the difficulty in predicting, the impact of a change on the performance of a production database system before actually implementing the change on the production database system.
Furthermore, database changes may not be easily tested on a production database system. First, applying database changes, even temporarily, to the production database system has a high risk of modifying execution plans for production queries. Since any modification of an execution plan of a query may lead to a degradation in performance of the query, DBAs generally prefer to avoid introducing such a risk for the purpose of testing database changes. Secondly, test executing queries on the production database system takes away system resources from production execution of queries and thus negatively impacts production database system performance.
Alternatively, DBAs may prefer to test database changes on a test database system, which is a replica of a production database system. However, testing database changes on a test database system may not yield accurate results because it may be practically impossible to reproduce the exact environment of the production database system on the test database system due to in-flight transactions at any given time on a busy production system and inability to restart the database for capturing the workload due to the business critical nature of the system. Any difference between the production database system and the test database system may impact an execution plan for a query and thus, yield a different performance metric for a database change.
Therefore, there is a need for a process for measuring the impact to the performance of a database system on which changes have been made or at least, determinatively identify any possible miss-measurement of the impact. This process enables DBAs to foresee where performance may improve or deteriorate and allow the DBAs to take corrective actions to fix the regressions before implementing the changes to the production database system.
The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.